前言

Day 04 結尾我寫下這句話：

明天 Day 05，要來測試 Gemini 的百萬 Token 長上下文，看看直接丟一整份技術文件進去，AI 能不能精準回答裡面的細節。

我挑了一份夠硬核的測試素材：STMicroelectronics 官方的 STM32H5 系列 Reference Manual（RM0481），3,766 頁，全是暫存器位址、Reset value、每個 bit 的定義，每個細節都能對答案。

沒想到光是「把資料弄進去」這一步，就連續踩了三道完全不同的牆，闖過去之後，準確度測試反而三題全對。

一、第一道牆：檔案本身就傳不上去

丟進 AI Studio 後直接報錯。查了官方文件才知道，Gemini 能處理的 PDF，單一檔案上限是 50MB、1,000 頁，這條規則同時套用在直接上傳跟用 Files API 上傳的情況。我這份手冊 72MB、3,766 頁，同時超過兩個上限。

解法是照章節邊界把手冊拆成幾份，每份控制在 1,000 頁以內；順手把過時的壓縮設定重新壓過，檔案也跟著大幅縮小。

二、第二道牆：兩份疊加，Token 預算就爆了

以為拆完就沒事，結果把其中兩份（各 940 頁）一起上傳，AI Studio 顯示：

輸入 Token：1,053,045 ／ 上限：1,048,576

只多了 8,469 個 Token，直接被擋下來。這揭露了兩層完全不同的限制：檔案本身有大小/頁數上限，對話的上下文視窗另外有自己的 Token 總量上限，兩者要分開檢查，符合前者不代表就安全通過後者。

三、第三道牆：畫面顯示還有餘裕，送出照樣超標

修正後改成一次只上傳一份 940 頁的檔案，畫面顯示輸入 Token 526,416／上限 1,048,576，明明還有將近一半的餘裕。結果送出後還是報錯超標。

我懷疑是延用了同一個對話、殘留了先前失敗的上下文，於是開了一個全新對話，只上傳這一份 940 頁檔案再測——結果依然超標。

這排除了「殘留上下文」的可能性，指向一個更值得留意的結論：AI Studio 顯示的 Token Usage，很可能只是用「平均每頁 Token 數」推算出來的估計值，不是模型實際處理這份文件時真正吃掉的數字。手冊裡的圖表密度並不平均——像系統架構圖、記憶體地圖這類整頁大型圖表，轉成視覺 Token 的成本可能比一般的暫存器位元圖高出不少，一旦這些重量級圖表集中出現在某個範圍內，實際消耗就可能大幅偏離平均估算。

畫面上看起來還有餘裕，不代表真的安全——這是今天最值得記住的一句話。

四、縮小切分粒度，三題全部測試成功

把切分粒度縮小到 235 頁左右一份之後，針對開頭、中間、结尾各自的分冊重新測試：

問題一（文件開頭）：這份文件開頭提到的內容屬於哪個功能模組？

→ Gemini 正確指出這是 STMicroelectronics 的 STM32H5 系列參考手冊（RM0481），核心是 Arm® Cortex®-M33，第 1 章「Documentation conventions」、第 2 章「Memory and bus architecture」。輸入 131,616 Token，全部落在上限之內。

問題二（TIM2/TIM3/TIM4/TIM5 章節）：TIMx_ECR 暫存器裡 IBLK[1:0] 欄位的三種設定值分別代表什麼意思？

→ Gemini 回答 00＝索引信號恆常有效、01＝在 tim_ti3 輸入上遮蔽、10＝在 tim_ti4 輸入上遮蔽，連保留值 11 都標注出來，跟手冊原文逐字對上。輸入 131,670 Token。

問題三（结尾章節）：结尾章節最後一個介紹到的暫存器名稱是什麼？

→ Gemini 回答「Package data register（第 67.3 節）」是结尾最後一個介紹的暫存器。我回頭查了手冊最後幾頁確認：第 67.3 節之後只剩「Important security notice」「Revision history」「法律聲明」，都沒有再定義任何新暫存器。輸入 133,295 Token。

三題全對，而且三次的輸入 Token 都落在 13 萬上下，跟 235 頁 × 每頁約 560 Token 的比率一致，離上限還有充足的緩衝空間。

五、對 DevPulse 專案的啟發

今天連續踩了三道牆才走到準確度測試，剛好對應三層要分開檢查的教訓：

1. 檔案格式的硬性限制（大小、頁數）跟對話的 Token 預算是兩件事，符合前者不代表就通過後者。
2. 疊加多份文件會讓 Token 消耗迅速累加，不能用單一檔案的預覽數字直接加總估算。
3. 畫面顯示的預覽 Token 數只是平均估算，不是保證。圖表密度不均勻的技術文件，就算預覽數字看起來安全，實際處理時仍可能超標；切分粒度寧可抓保守一點（例如控制在 200~300 頁），也不要精算到剛好卡在上限邊緣。

好消息是：只要切分粒度抓得夠保守，Gemini 對細節的掌握其實相當精準——三題涵蓋開頭、中段、结尾都答對，證明長上下文能力本身沒問題，問題出在「怎麼把資料安全地送進去」。這對 DevPulse 之後要不要支援「讀取長文件」這個功能，是個必要的測試。

今日 Checklist

• [x] 找一份細節密度夠高、事實可驗證的長篇技術文件（STM32H5 官方 Reference Manual）
• [x] 上傳失敗，查出 Gemini 對 PDF 有 50MB / 1,000 頁的硬性上限
• [x] 把手冊拆成數份，重新壓縮後都在限制以內
• [x] 疊加兩份分冊超出百萬 Token 對話上限
• [x] 單一 940 頁檔案，畫面顯示還有餘裕，送出依然超標，排除殘留上下文的可能性
• [x] 縮小切分粒度到 235 頁，開頭、中間、结尾三題全部測試成功

小結

今天原本只想測「AI 記不記得住細節」，結果連續撞了三道牆，一道比一道有意思：檔案大小超標、疊加多份文件讓 Token 預算爆掉、最後發現畫面顯示還有餘裕送出照樣超標。縮小切分粒度到 235 頁後，開頭、中段、结尾三題總算全部測試成功，Gemini 的回答也都精準對上手冊原文。這提醒我，長上下文能力本身值得信賴，真正的挑戰在「怎麼把資料安全地餵進去」——之後設計 DevPulse 要怎麼讀長文件，切分粒度寧可保守，也不要壓線嘗試。

明天 Day 06，要把 Day 03~05 累積的 Prompt 設計整理成一套可重複套用的標準流程，準備進入下一階段。